Where is this coming from @loftlifter31 ?

https://github.com/system76/firmware-open/tree/master/models/galp5

Ideally there is a script downloading me.rom from a specific commit, so that this repo doesn't grow with blobs, just like for other boards, see blobs scripts.

Alternatively, as other coreboot forks do, there is seperate blobs. Those might be under coreboot blobs already downloaded, I haven't verified either.

Tldr:we would merge a blog of 5mb in this tree that will change later.

See past blobs in their repo, changed 5+ times already https://github.com/system76/firmware-open/commits/master/models/galp5/me.rom

This is tip of fork at time of writing system76/coreboot@6da534f

This was generated using modules/coreboot Makefile helper. Feel free to finetune with:
docker run -e DISPLAY=$DISPLAY --network host --rm -ti -v $(pwd):$(pwd) -w $(pwd) tlaurion/heads-dev-env:latest -- make BOARD=galp5 coreboot.modify_and_save_oldconfig_in_place

This was generated using modules/linux Makefile helper. Feel free to finetune with:
docker run -e DISPLAY=$DISPLAY --network host --rm -ti -v $(pwd):$(pwd) -w $(pwd) tlaurion/heads-dev-env:latest -- make BOARD=galp5 linux.modify_and_save_oldconfig_in_place

Absolutely needed

I wasn't sure what to put in this config file. The system76 build process doesn't use it since they use coreboot with an edk2 payload. I tried copying the config for the running kernel but that has a ton of multimedia drivers and created a monster sized kernel 80+ Mb. Too big for the rom. So in the end I just copied the linux config from another board. x230 I think since it uses close to the same kernel version 5.15 How will I know what FB to set here?

I wasn't sure what to put in this config file. The system76 build process doesn't use it since they use coreboot with an edk2 payload. I tried copying the config for the running kernel but that has a ton of multimedia drivers and created a monster sized kernel 80+ Mb. Too big for the rom. So in the end I just copied the linux config from another board. x230 I think since it uses close to the same kernel version 5.15 How will I know what FB to set here?

Does it work?
It should be GOP (provided by fsp for iGPU to drive coreboot FB) and then efifb as said.

Only librem 11 is goon driven under heads today, everything else is libgfxinit driven under coreboot.

So if GOP initialize 2d FB enough so coreboot is happy with linear FB init, then efifb from kernel can reuse it, then you would be good to go on that level.

Test results?

Also this or is not based on x230 config anymore. Neither the same kernel ver, coreboot ver nor configs.

This is coreboot config derivate of librem 11, and coreboot fork using latest commit from their coreboot fork.

Have you reviewed all the changes? See individual commit logs and file changes.

@loftlifter31 system76 coreboot fork seems to be missing some patches from upstream. See patches/coreboot-24.02.01 for reference, added HEAP_SIZE patch needed for bootsplash to work, others might be missing

CONFIG_FB_EFI=y works ok in the linux.config file. If additional info is needed on this, I can post the relevant lines from the compile config file used to build the kernel that shipped with the laptop.

Should work, as for librem_11

Not sure how the keyboard is connected. If PS2, remove.

It's a laptop so the keyboard is built in.

It's a laptop so the keyboard is built in.

Doesn't mean much unfortunately without having laptop in hands. It either needs to be ps2/usb and if usb, drivers needs to loaded early under Heads.

Hence why I raise your attention there.
Its cheaper for manufacturers nowaday to do usb, many do that. I dunno their implementation.

@tlaurion CONFIG_SUPPORT_USB_KEYBOARD=y allows the user to enable USB keyboard support in config. It's off by default. I provide this for Librems due to popular demand.

You're thinking of CONFIG_USB_KEYBOARD_REQUIRED=y which means the device only has USB keyboards.

I'm not familiar with this hardware, but typically the internal keyboard is a PS/2 keyboard (well, really provided by the EC as an 8042 interface, no actual PS/2 port or signaling, but I digress). So I think you have this right @loftlifter31

@loftlifter31 optional, runtime configurable option under 76d2dc8

Points to your blobs. Not checked validity

Might need to be bumped to 0x400000 otherwise no bootsplash. Patch under purism fork and 24.02.01 patches/dir

Correct. There is no bootplash at this setting, but that is not a problem for me.

Are we trying to get galp5 for your sole usage or for everybody else? That will change my involvement in this effort.

My primary concern at this point is to get it working for myself according to my needs. However, I don't see any problem with testing alternate configurations which may benefit others, such as increasing the heap size.

Ha, nope. Sorry, coreboot forks have their own logic, and doing real.clean* doesn't remove the .patched flag.
Working on a fix and pushing.

Ha. Realized the two patches were abandoned and https://review.coreboot.org/c/coreboot/+/83895 was merged instead.... @JonathonHall-Purism

Let's wait and see if 127e5df and #1795 builds from CI.

If not, https://review.coreboot.org/c/coreboot/+/83894/2 might as well be needed.

Neglect #1774 (comment) referred patches, deleted in latest commit here and under #1795

Still no bootsplash with heap set to 0x400000

@loftlifter31 unclear what ethernet controller is present under HCL https://tech-docs.system76.com/models/galp5/README.html you might need to adapt

Not sure why I would need ethernet during boot up. Once control is passed to full linux kernel that will take care of loading correct drivers, yes?

Not sure why I would need ethernet during boot up. Once control is passed to full linux kernel that will take care of loading correct drivers, yes?

This driver needs to be right (e1000e, igb whatnot) to be able to use network-init-recovery script (which syncs time through ntp and get an address from dhcp prior) from recovery shell today. It's completely on demand and nothing today does the loading of the driver automatically outside of this codepath.

Heads hopefully will evolve into squashfs+overlayfs overlays so that things can be pulled from the network (wyng, docker whatever) depending of the use case pushed by the oem down to its users (dasharo DTS being one desired case, to bypass need of ipxe: we could wget kernel +initrd and kexec into it), another one being python3 overlayfs to jump into getting system state restoration as a service.

Note that the board config as it is already included android network tethering drivers also prompting the user to be used transparently through network-init-recovery today.

Tldr: on demand network access, loading drivers not on standard boot path, measures then load additional drivers, changing PCR content and preventing heads to release secrets that were sealed to unseal only on default boot path. So loading any on-demand driver will prevent efficiently any secret to be unsealed. Same applies to recovery shell access: doing on demand operations extend PCR banks which invalidates measurements .

Todo: Getting the right Ethernet driver there is needed for on-demand networking. Gotta figure out if it's igb e1000 or e1000e

Docs say it should come with Intel NIC however mine seems to come with Realtek 8111 chipset.

Docs say it should come with Intel NIC however mine seems to come with Realtek 8111 chipset.

need actual loaded driver and dependencies from booted linux os lsmod

driver is r8169. No listed dependencies.

@loftlifter31 this is console output (equivalent of cbmem console output) saved in SPI.
0x20000 might not be enough, and more debugging activation might be needed.

But this will permit to take a falshrom/flashprog backup externally and investigate the content in case of a bricked system and post those logs to make this go faster in case EFIFB/libgfxinit/GOP not working as expected.